Semaphores

Semaphores

A semaphore is a memory object that represents the state of a shared resource. The content of a semaphore is an integer count, representing the number of resource units now available. Typically the count is 1, and the semaphore represents the availability of a single object such as a table or file.

A process that needs to use the resource executes a "P" operation on the semaphore. This operation tests and decrements the count in the semaphore. If the count is greater than zero before the operation, at least one resource unit is available. The count is reduced by 1 and the process continues executing. When the count is not greater than zero, the process is blocked until a resource unit is available; then it continues. In either case, following a P operation, the process knows that it has exclusive use of a resource unit.

When it finishes its work, the process releases the resource by executing a "V" operation on the semaphore. This operation increments the count. It also unblocks any process that might be blocked in a P operation, waiting for the resource. If more than one process is waiting, the one that has waited longest is released first (FIFO order).

Tip: Useful mnemonics for P and V: P depletes the resource. V revives it. IRIX supports two forms of semaphore: SVR4-compatible, and Silicon Graphics.

IRIX Semaphores

IRIX supports a set of semaphore operations designed for low-overhead coordination between multiple concurrent processes. You create these semaphores within a shared arena created with usinit() (see "IRIX Shared Memory Arenas"). The usnewsema() call creates a semaphore. You specify the arena handle and the initial value for the semaphore (that is, the count of resources that it represents, typically 1).

To acquire a resource, blocking if it is not available, a process applies the uspsema() call to the semaphore. To test the resource, acquiring it if it is available but not blocking when it is in use, a process can call uscpsema(). To release the resource, a process calls usvsema().

IRIX also supports a parallel set of "pollable" semaphores. The P operation on a pollable semaphores does not block when the resource is in use. Instead, it returns a flag value, and the process must use the poll() system call to find out when a V operation has made the resource available.

IRIX semaphores support "metering" (use counts) and debug tracing. You can turn either facility on and off dynamically. By metering a semaphore, you can find out how often processes actually block in a P operation. This can reveal whether or not a resource is a bottleneck to performance.

For more information on semaphores, refer to Topics in IRIX Programming, and to the usnewsema(3), usnewpollsema(3), uspsems(3), usvsema(3), and poll(2) reference pages. The sample program shown in "Interprocess Communication" uses IRIX semaphores, and demonstrates the use of metering information.

SVR4-Compatible Semaphores

SVR4-compatible semaphores are created in sets of one or more--typically a set contains all the semaphores that one application needs. A set is created by a semget() call, which specifies an integer key to identify the set and access permissions for the set.

Like a shared memory segment (see "SVR4-Compatible Shared Memory"), a set of semaphores is somewhat like a file in that it

has a user and group ID from the process that created it
has read and write access permissions for owner, group and world
continues to exist after its creating process ends.

Once a set of semaphores exists, any other process can issue semget() with the same key. If the user and group ID of the calling process have access permission, the process can use the semaphores in the set.

SVR4-compatible semaphores do not support the conventional P and V operations. Instead, the semop() system call supplies a wider range of operations, including incrementing and decrementing counts by more than 1. The semop() call supports concurrent operations on multiple semaphores at once. This is convenient in some cases because it allows you to claim more than one resource simultaneously, without danger of deadlock.

For sample code and more information on SVR4-compatible semaphores, refer to Topics in IRIX Programming, and to the ipcst(1), semget(2), semctl(2), and semop(2) reference pages. The administration of SVR4-compatible semaphores is covered in the IRIX Advanced Site and Server Administrator Guide.

Tip: If you require portability, use SVR4-compatible semaphores. Otherwise, the IRIX semaphore implementation is faster, has more features, and works with the IRIX shared-memory implementation.